These settings may adversely affect your download performance. Be very careful if you change them.
Incoming/Outgoing peer connection encryption
The encryption used is the standard BitTorrent message stream encryption, which features a Diffie-Helmann key exchange followed by RC4 stream encryption. This scheme is not 100% secure against 'man in the middle' attacks, but does offer a good level of privacy. It is recommended all users set the default "Encrypted Preferred" and "Accept Either" unless a very slow CPU is used, in which case the user should set "Unencrypted Preferred" and "Accept Either".
Outgoing peer connection Protocol
As yet undocumented...
Incoming peer connection Protocol
As yet undocumented...
Peer connect/login timeouts
As yet undocumented...
Maximum peer connections per transfer
This controls how many outgoing connections are made in each transfer, and how fast they are made. It also limits the amount of incoming connections that are accepted. Tixati will attempt to always use about 70% of the maximum, and will actively make outgoing connections until that figure is met. Incoming connections will be rejected if the maximum connection limit has been reached.
If you are on a very fast internet connection (40Mbps or higher, which is rare), you may achive better results in SOME swarms by setting this number higher. Most users should leave this at 55.
This number can also be customized per-transfer. Go into a tranfer's "Options" property tab, and look in the "Peers" section where you will find a configurable maximum for the single transfer.
Maximum concurrent outgoing TCP connection attempts
This should be set to 8 for Windows systems, and 100 for Linux systems. Windows has a TCP/IP stack that is purposely crippled as part of a 'security feature', and will not make any more than 10 outgoing connections at a time. Unfortunately, this 'security feature' was implemented very poorly, and when any piece of software exceeds the limit, it can cause excessive amounts of socket handles to be leaked within the TCP/IP stack due to the handles not being properly released from the internal outgoing connection queue when a connection attempt is aborted and a handle is closed by the application. This will cause the TCP/IP stack to become unresponsive until all outgoing attempts have ceased for several minutes to wait for these orphaned handles to make their way through the queue. To prevent these problems, keep this setting at 8 or under.
Maximum concurrent outgoing UDP connection attempts
As yet undocumented...
Dual conn attempt non-pref proto skip minimum margin %
As yet undocumented...
Network mode
Users that have access to networking may change this setting to take advantage of the newer IP system.
Local IP IPv4/IPv6 addresses
This setting is provided for expert users that have multiple internet connections and need to specify a local address to bind all connections to. Most users should leave this setting blank.
Advanced Socket Options
As yet undocumented...
